The danger with automatic refactoring is simply that if your eyes didn't see what you did to the code, you won't know the code. You haven't experienced the code. You haven't "been there, done that".
i.e. automated refactoring versus manual refactoring.
The danger of manual refactoring is that you may not make changes to all the appropriate places - but at least your compiler will help you out, if you managed to make a mistake and not refactor all the items (with strong static typing that is).
On large projects, automatic refactoring might make sense.. because it may be tedious to do large amounts refactoring. But you have to ask yourself: why does this refactoring need to be done? Should you manually refactor your code to learn why the refactor should be done? If you automatically refactor your code, you may not learn why or what the reason was for your design mistake. The newly refactored code will not be as recognizable to you since you did not go in and make changes with your hands; the automation system did that for you.
If you didn't see the murder take place, you probably won't know the details about the murder scene! Better to be there and watch in some cases.
If you do have an automated refactoring system that you use, make sure that you look over any changes the refactoring system made. And remember to ask yourself "why did I have to refactor this code? Should I learn more about my programming language, and should I improve my design skills? Or should I continually refactor my messy code?".
When doing some refactoring, such as changing records to classes, or changing some loose procedures and functions into organized records or classes, you usually have to do the work any way. No editor could possibly automatically guess where to put your procedures or functions.
For situations like renaming "Button1" to "PressMe" or "Procedure1" to "SetupThis", automatic refactoring can be useful to save your hands. For other situations, it may be dangerous.
|
